home *** CD-ROM | disk | FTP | other *** search
/ BBS Toolkit / BBS Toolkit.iso / rbbs_pc / rbbsdocs.zip / RBBSDOCS.8 < prev    next >
Text File  |  1990-11-05  |  9KB  |  155 lines
  1.  
  2.  
  3.  
  4.     UNIQUELY IDENTIFYING YOUR CALLERS                                       8-1
  5.  
  6.  
  7.     8. UNIQUELY IDENTIFYING YOUR CALLERS
  8.     ------------------------------------
  9.     All  callers need  a way  to identify  themselves to  RBBS-PC and  to other
  10.     callers.   RBBS-PC  expects each  caller to  set a  password so  that other
  11.     callers  cannot easily pretend to be that  caller.  Callers are most easily
  12.     known  on bulletin boards  the same way  they are known  in real life  - by
  13.     first and last name.  This is why the default configuration in RBBS-PC uses
  14.     first and last name to IDENTIFY users.  The first/last name is the caller's
  15.     identity or ID.
  16.  
  17.     RBBS-PC also allows  the SysOp  to identify callers  uniquely by  something
  18.     other than their first and last names.  Perhaps the SysOp  wants a one word
  19.     alias to  be allowed, or perhaps callers must use a preassigned access code
  20.     (access code, employee number,  account number, etc.).  RBBS-PC  allows ANY
  21.     FIELD inside the users file to be used for identification.  Since there are
  22.     empty, unused areas  in the user file, a SysOp can  even create a new field
  23.     to be used for caller identification.
  24.  
  25.     When  anything other  than name  is used to  identify users,  RBBS-PC still
  26.     wants  callers  to  specify  their  names.    It  just  does  not use  that
  27.     information to identify them.
  28.  
  29.     A fairly common problem on bulletin board systems with large  user lists is
  30.     that two callers can have the same first and last name.  A caller discovers
  31.     this when they are unexpectedly asked for a password on the first call to a
  32.     new  system, indicating  that another  caller has  already used  that name.
  33.     Further,  since  RBBS-PC  is  used  world-wide  many  non-English  speaking
  34.     countries have callers with names that have embedded  blanks, etc.  RBBS-PC
  35.     alleviates  this  problem by  allowing interior  blanks  in first  and last
  36.     names.  Thus JIM  JONES can register as JIM K JONES or  JIM JONES SR or JIM
  37.     JONES III.
  38.  
  39.     By  allowing ANY  field  inside the  user  record to  be  used to  uniquely
  40.     identify individual callers, RBBS-PC alleviates the basic problem of having
  41.     two callers with the same name.
  42.  
  43.     This additional INDIVIDUATION field is used to distinguish callers with the
  44.     same ID.  When individuation is used, callers will have to specify both the
  45.     identifying and individuation field.  Both are used to find a record in the
  46.     users file.  This individuation  field can likewise be a new  field created
  47.     by the SysOp.   For example, the SysOp can specify that callers be uniquely
  48.     identified  by both  their name  and their  CITY/STATE.   Alternatively the
  49.     SysOp  can specify  that callers  are to  be uniquely  identified by  their
  50.     telephone number, which  would be a new  field for RBBS-PC to  store.  Note
  51.     that when using  individuation, ALL callers must use it,  not just the ones
  52.     with identical names.
  53.  
  54.     8.1 Setting Up Identifying and Individuation Fields
  55.     ---------------------------------------------------
  56.     The  identifying  and individuation  fields  in RBBS-PC  are  controlled by
  57.     parameter 41  through 46 in  CONFIG.   The default is  to use  the caller's
  58.     first and last name to uniquely identify a user.
  59.  
  60.     The fields available to uniquely identify a caller (other than the caller's
  61.     first and last name) are  designated in CONFIG by the starting  position in
  62.     the  users file and length.  It  is essential therefore to understand WHERE
  63.     FIELDS ARE  STORED IN  THE USER FILE.   Consult Appendix  A for  a detailed
  64.     layout of the user file.
  65.  
  66.  
  67.  
  68.     RBBS-PC 17.3A            TECHNICAL REFERENCE MANUAL                     8-2
  69.  
  70.  
  71.     RBBS-PC's flexibility requires care when selecting the  locations of fields
  72.     used to identify and individuate, because options can be selected that make
  73.     no  sense.   For example,  it is  possible to  specify the  user preference
  74.     field, which  means that  every time  a user  changed preferences, such  as
  75.     default protocol, the user would have a different ID.
  76.  
  77.     There are only  two fields in the user file that make sense for identifying
  78.     users:
  79.  
  80.       1) first/last name (column positions 1-31), or
  81.       2) a  field designated  by  you as  the SysOp  for your  RBBS-PC.   For a
  82.          SysOp-designated field, only 4 choices make sense:
  83.               a) none,
  84.               b) name (columns 1-31),
  85.               c) city/state (columns 63-86), or
  86.               d) positions 87-97 in the user record currently "unused."
  87.  
  88.     Positions 87-97 of the users record (currently unused) provides a potential
  89.     11  columns  to use  for SysOp  designated fields.    However, there  is no
  90.     guarantee that  these positions  will not  be used  in  future releases  of
  91.     RBBS-PC.  Additional  fields will be  used from the far  right.  Any  SysOp
  92.     intending to utilize  this area of the users record is  safest if the field
  93.     selected begins in column 87 and is as short as possible.
  94.  
  95.     When a  SysOp-designated field is created,  the SysOp must  also supply the
  96.     prompt to be used with  the field.  The prompt is what is  displayed to the
  97.     caller when asking for the value of the field.
  98.  
  99.     RBBS-PC uses the callers first and last name for the "to" and "from" fields
  100.     for messages even  when the users  name is not  the field used  to uniquely
  101.     identify callers.
  102.  
  103.     8.2 Preloading Identities For Instant Access
  104.     --------------------------------------------
  105.     SysOps who operate  bulletin boards that  are open to  new callers have  no
  106.     problems giving a  new caller instant access --   new callers register, set
  107.     their identity and password, and are recorded in the USER file.
  108.  
  109.     SysOps  that  operate     bulletin  boards  that  are  only   available  by
  110.     subscription  or  who delay  access  operate differently  --   a  user must
  111.     already  know and be able to state identity, individuation, and password in
  112.     order to  get on.  To  add a new user,  the values of these  fields must be
  113.     communicated back  to the  caller in  order for them  to have  access.   To
  114.     overcome this cumbersome approach,  some SysOps allow new callers  on their
  115.     system (at a  reduced security level) and then raise  the security level of
  116.     the caller once  the caller has met whatever criteria the SysOp has set for
  117.     access to the system.
  118.  
  119.     Typically new callers must call  back and continue to check to see if their
  120.     security level  has been raised.   Systems that  do not let new  callers on
  121.     require the  SysOp to enter the appropriate  information for each new user,
  122.     contact the new caller by mail or  phone, and let them know how to  connect
  123.     to  the RBBS-PC.   Both  approaches  introduce delays  to  new callers  for
  124.     getting on and additional time, expense and overhead for the SysOp.
  125.  
  126.     RBBS-PC provides a systematic solution to the problem of delayed access for
  127.     new user.  A SysOp can add a user WITH NO VALUE FOR THE INDIVIDUATION FIELD
  128.     OR PASSWORD.  These fields can be left blank.  When a caller logs on with a
  129.     proper ID  and RBBS-PC  finds an  individuation value  or password that  is
  130.  
  131.  
  132.  
  133.     UNIQUELY IDENTIFYING YOUR CALLERS                                       8-3
  134.  
  135.  
  136.     blank, it lets the caller set the value of those fields without requiring a
  137.     match.   Subsequent calls, but not the  first, must match the value set for
  138.     individuation and password.
  139.  
  140.     Even though a SysOp can add a user and leave the password and individuation
  141.     blank,  this still requires that the SysOp add the user only after an ID is
  142.     agreed to  by both parties.  What if this  access is still not fast enough?
  143.     The solution provided  by RBBS-PC is  for the SysOp  to "pre-load" IDs  and
  144.     give out a  pre-loaded ID  to the caller  for instant  access, so that  the
  145.     client does not have to wait even for the SysOp to add the ID.  Since there
  146.     is no way to  set in advance how a  user wants to be identified,  the SysOp
  147.     can set up essentially random account IDs which are difficult to guess.
  148.  
  149.     Callers who pre-pay the subscription  fees can be given a  valid pre-loaded
  150.     ID for instant access.  The ability of RBBS-PC to use any field for  an ID,
  151.     and let the  first call set individuation and password,  means that RBBS-PC
  152.     can support  boards  where instant  access  is  a critical  part  of  their
  153.     service.
  154.  
  155.